Date: Tue, 5 Apr 94 04:30:12 PDT 

From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu> 
Errors-To: Ham-Digital-Errors@UCSD.Edu 

Reply-To: Ham-Digital@UCSD.Edu 

Precedence: Bulk 

Subject: Ham-Digital Digest V94 #98 

To: Ham-Digital 


Ham-Digital Digest Tue, 5 Apr 94 Volume 94 : Issue 98 


Today's Topics: 
Baycom modem and AMTOR? 
CDE antenna rotor 
Heathkit HD-15 Phonepatch Manual? 
JNOS and SAM 
MFJ 120C & Netrom 
Unknown RTTY mode 


Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu> 
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: Tue, 5 Apr 94 12:52:58 +0400 

From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!pipex!uknet!EU.net! 
news.eunet.fi!news.spb.su!satisfy.kiae.su!kiae!relcom!demos1! dnews- 
server@network.ucsd.edu 

Subject: Baycom modem and AMTOR? 

To: ham-digital@ucsd.edu 


Does anyone have the info about the possibility to 
operate AMTOR with a simple modem in "Baycom" style. 
Here is home made modem based on TCM3105 with an 
external modulator (for 300 baud) on 2 IC's and an 
active filters on 386/7 dx 4QmHz at clone. 

It's working well PR with software Baycom V1.5 
and RTTY with Hamcomm V2.1, but i am still looking 
for any other software, which allow to operate with a 
"normal" terminal program, such a SP,GP... or in any 
other mode (AMTOR, PACTOR) 


I can't find this info here on local VHF BBS, 
because the nearest one located abt 200 km from here. 
So it is only one way to find it - this place. 


Thank's 
Andrey Petrov, UALTFA. 


Russia 
Novgorod State University 
pap@pltx.nov.su 


Date: Mon, 4 Apr 1994 21:20:57 GMT 

From: amd!news.kpc.com!kpc!nat@decwrl.dec.com 
Subject: CDE antenna rotor 

To: ham-digital@ucsd.edu 


Hi, 

I bought a CDE antenna rotor at a hamfest last year. The rotor is 

fine but the controller seems to be flaky when I try to point the antenna 
between N and West. Here are the details from the back of the controller. 


Model AR-33 115 V.A.C 

60 cycle 1 Amp 

Mfd by 

Cornell-Dubilier 

Electronics Div. 

Federal Pacific Electric Co. 
Fuquay-Varina, North Carolina. 
Patent No. 3.043,998 


Series 1820. 


The terminal strip has 5 wires. If anybody has a copy of the schematics 

of the controller I'd like to get a copy of it. Could some knowledgeable soul 
explain how the 5 wire system works. I opened the controller and the 

position dial is nice wire wound resistor of 1K ohm resistance which has 

been hooked up as a variable resistor and not a potential devider. There is 

a large capacitor across terminal 1 and 5. There is a transfromer with a 

center tapped secondary. The outer terminals are connected to terminals 2 and 4. 
Voltage between one of the outer terminals and the center tap is 14.2 volts. 

The center tap is connected to a ground trace on the circuit board. 


Is the controller setup as a bridge where the dial in the controller 

is one of the arms and a similar dial up in the rotor is the other arm. 
The rotor stops moving when the 2 arms get balanced. Any information will be 
of great help 


Sincerely 
Nat. 


Natarajan Gurumoorthy AB6SJ Kubota Pacific Computer, Inc. 
nat@kpc.com 2630 Walsh Avenue 
Phone 408 987 3341 Santa Clara, California 95051. 


Date: Mon, 4 Apr 1994 20:16:30 GMT 

From: agate!howland.reston.ans.net!wupost!crcnis1.unl.edu!news.unomaha.edu! 
news.nevada.edu! jimi!envoy!jim@ames.arpa 

Subject: Heathkit HD-15 Phonepatch Manual? 

To: ham-digital@ucsd.edu 


I recenly aquired a Heath HD-15 phone patch without a manual. Is there 
someone who would make a copy for me? I will gladly pay expenses. Thank 
you very much. 


Jim Mueller | Work : (702) 689-3111 | jim@shadow.scs.unr.edu 
11865 Deodar Way | Home : (702) 677-2775 | WB7AUE@KE7KD.#NONEV.NV.USA.NOAM 
Reno, NV 89506 | | 


Date: 5 Apr 1994 03:01:12 GMT 

From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!gatech!newsxfer.itd.umich.edu! 
news1.oakland.edu! chaos! ron@network.ucsd.edu 

Subject: JNOS and SAM 

To: ham-digital@ucsd.edu 


zenn Martin (martin@server.cdpa.state.ms.US) wrote: 

: One other problem though. The command prompt is not cleared (ie, it still 

: contains the command just entered) whenever the command causes you to 

: switch to another session. When I return to the console screen the previous 
: command is still on the command line following the prompt. The command IS 


Look on some archive sites for a patch for Borland C++ 2.0. This sounds just 
like the problem that one of their library files had. I used to have to put 
the patch on it when I ran 2.0, I'm running Borland C++ 3.1 now and it 
works fine. 


: 73 - John 
73, Ron N8FOW 


Date: 5 Apr 94 03:00:58 GMT 

From: dog.ee.lbl.gov!agate!howland.reston.ans.net!vixen.cso.uiuc.edu! 
prairienet.org!k9cw@ucbvax.berkeley.edu 

Subject: MFJ 120C & Netrom 

To: ham-digital@ucsd.edu 


In a previous article, chuckv@comtch.iea.com (Chuck Vyverberg) says: 


>I saw some messages the last couple fo week giving detailed instructions 
>on how to get the MFJ1270C TNC to run as a netrom node. 
> 


To use the MFJ1270C with netrom or TheNET, all you need to do is program 
a 27256 EPROM with the modified firmware module (V2.08B is the one I have 
in three digi's in central IL) and plug it in. No circuit mods are 
required. 


Installing an X1J node is another matter... 


73, Drew 

Rec eee ee ee ee eee eee eee eee Ree eee eee ee eee ee eee eee eee eee * 
| Andrew B. White K9CW | internet: k9cw@prairienet.org 

| ABW Associates, Ltd. | phone/fax: 217-643-7327 

Ae ee en ee ee eee ee eee ee eee eee eee Ree eee eee ee ee ee ee ee ee eee eee eee eee * 


Date: Mon, 4 Apr 1994 16:18:29 GMT 
From: rit!sunsrvr6!jdc@cs.rochester.edu 
Subject: Unknown RTTY mode 

To: ham-digital@ucsd.edu 


In article <wilsonjhCnGKA1.Ix4@netcom.com>, 

John Wilson <wilsonjh@netcom.com> wrote: 

>I have been monitoring some "utility" signals using an AEA PK232-MBX, 
>and have run across many strong signals that the PK232 cannot decode. 
>These sound like ordinary two-tone FSK RTTY signals. 

>They are often, but not always in the HF maritime bands (6, 8, 12, etc. 
>Mhz), and the signal identification feature on the PD232 shows 

>75 baud and mode "unknown". I hear these signals with both narrow 


>and wide shifts. Anybody know what they are? A special code for an 
>Oriental language? Encrypted data? Something altogether else? Anybody 
>know how to copy them? 

> 

>Tnx es 73, 

>John K3KXJ 


I have also run into these signals. I always thought the inability 
to decode them was due to shortcomings in hardware interface and 
software. (I use Hamcom 2.2 with the 741 op-amp interface.) But 
this may not be the case. 


After receiving the last half of a weather-fax map, the station switched 
to RTTY. It was strong signal, and the weather-fax came in OK. After 
it switched to RTTY I fired up Hamcom 2.2. It was easy to figure out 
frequency shift and baud rate with the "Spectrum" and "Bit length" 
screens. But the text was undeciperable gobbledygook. 


Seems like it must be some type of maritime-related station. Anybody 
have more specific info? 


73...Jim N2VNO 


Date: Mon, 4 Apr 1994 22:17:24 GMT 

From: ihnp4.ucsd.edu!library.ucla.edu!europa.eng.gstefsd.com!uhog.mit.edu! 
news .mtholyoke. edu! world! dts@network.ucsd.edu 

To: ham-digital@ucsd.edu 


References <2nejic$j75@hp-col.col.hp.com>, <CnJL6K.Loq@world.std.com>, 
<2nph5e$djt@hpbab.mentorg.com>.mthol 
Subject : Re: NTS traffic on packet 


In article <2nph5e$djt@hpbab.mentorg.com> Hank_Oredson@mentorg.com writes: 

>In article <CnJL6K.Loq@world.std.com>, dts@world.std.com (Daniel T Senie) writes: 
>|> In article <2nejic$j75@hp-col.col.hp.com> jms@col.hp.com (Mike Stansberry) 
writes: 

>|> >Jeffrey D. Angus (jangus@skyld.grendel.com) wrote: 

> 

>|> I have lately seen traffic duplicated 2 or 3 times. One message I sent to 
>|> my STM at the other end of the section got there 4 times. We have had 

>|> a rash of multiple NTS deliveries. 

> 

>This is a very serious problem. 

> 

>There are many possible causes, but they all come down to poor operating 
>practices by the sysops. If the sysops had things set up reasonably, 


>and made certain their systems were operating properly, then there would 
>be no (zero, zilch, none) duplicated bulletins. 

> 

>Personal messages and NTS traffic are handled differently. 

>Duplicates are allowed to occur, rather than lose an occasional message. 
>However, these duplicates should be rare: 1 in 1000 perhaps. 


This raises some alarm bells with me. Networks need to either send or not 
send messages. Protocols are designed to be able to be sure of such things. 
Could you imagine if something like an international money transfer were 
occasionally duplicated on the commercial networks? It sounds like the 
protocols involved (in nthis case, the handling methods) may need some 
review. 


Why is the software designed to allow even an occasional duplicate? Why 
is there otherwise the possibility of a lost message? 


> 

>Sounds like the sysops involved have not done a very good job of 

>getting their systems to work. 

> 

>You can't just "Load the BBS software and away you go." 

>It takes thought, planning, cooperation, and coordination to make a network 
>work properly. In the past couple years, I have noticed a distinct lack of 
>all of the above in many parts of the BBS network. 

> 

>Perhaps time for some organization to take a leadership postion here? 

> 

>(ARRL, where are you when you are needed?) 


Well, I am the local ARRL person (Section Manager). I'm gathering information 
so that I can intelligently address the appropriate people about the 
problem. 


In this area the North East Digital Association runs the AX.25 net, so it 
would seem to make sense that they are the ones to take the leadership 
position on this. Perhaps I need to appoint an Assistant Section Manager 
who can oversee packet operations, or something like that... 


> 
> ... Hank 

> 

>-- 

> 

>Hank Oredson @ Mentor Graphics 
>Internet : hank_oredson@mentorg.com 
>Amateur Radio: WORLI@WORLI.OR.USA.NOAM 


Thanks for your response, by the way. I do appreciate that you and others 
put in quite a bit of time on the BBS software. Overall things seem to work 
pretty well, but it gives a false sense of security sometimes, when things 
like the multitude of dupes we've seen happen. 


thanks and 73, 


Dan N1JEB SM WMA 


Daniel Senie Internet: dts@world.std.com 
Daniel Senie Consulting nijeb@world.std.com 
508-779-0439 Compusetrve: 74176 ,1347 


Date: Mon, 4 Apr 1994 22:24:16 GMT 
From: spsgate!mogate! newsgate! dtsdevO! kinzer@uunet.uu.net 
To: ham-digital@ucsd.edu 


References <2nejic$j75@hp-col.col.hp.com>, <CnJL6K.Loq@world.std.com>, 
<2nph5e$djt@hpbab.mentorg.com>evO 
Subject : Re: NTS traffic on packet 


All I can say is I'm glad no one is charged with maintaining the 
ionosphere. Just imagine the bitching out they'd get. 


I do have one positive contribution to make. If duplicate messages are 
really a big problem, then each (or each destination) node could keep a 
hash code of the content of every message that has been seen in the past 
N days. If any hash code matches, delete the message without passing 
it along or making it available for download. Ignoring headers allows 
messages that have taken different routes to still be zapped. Using a 
good hash and enough bits and enough days history you could select the 
probability of erroneously dropping a non-duplicate to less than the 
probability of an NTS operator accepting a message yet dying before he 
delivers it. 


Say 12 bits for date received (would allow over 10 years of data to 
accumulate and still allow for deleting by day, talk about overkill) and 
52 bits of hash for a total of 8 bytes retained per message. If 100 
messages arrived daily, and we kept 120 days worth, we would be keeping 
96K bytes of data, not even a floppy disk worth. There would be 12,000 
hash patterns (no duplicates) from a data space of 2%52, giving the 
possibility of erroneously deleting a random incoming message of 
0.Q000000000266 percent. Add a few more bits to the hash code if that's 
not good enough for you. Even as it is, at 100 messages daily, it means 


only one dropped message every 10 million years on average. I don't think 
this will be the weak link in delivering messages. 


Of course, I don't claim to be a mathematician or statistician, so the 
above numbers should be taken as a general approximation at best. Still, 
it's one avenue open for exploration. 


-dave 


Date: 5 Apr 1994 02:20:07 GMT 
From: nothing.ucsd.edu! brian@network.ucsd.edu 
To: ham-digital@ucsd.edu 


References <2n7bup$3v3@hpbab.mentorg.com>, 
<1994Mar29 .100554.3059@hemlock.cray.com>, <2nphhd$djt@hpbab.mentorg.com> 
Subject : Re: [REPOST] The # in PBBS addresses.... 


In article <2nphhd$djt@hpbab.mentorg.com> Hank_Oredson@mentorg.com writes: 
>You are perhaps talking about the internet, which chose to ignore 
>the existing use of NA in one of it's connected networks? 


Oh jeez, Hank, stop making things up. The AMPR.ORG domain has never used 
the ham bbs hierarchical routing/addressing scheme to name hosts. 


With some exceptions, the namespace of the AMPR.ORG domain consists 
solely of callsigns within the domain. Names are not routes, routes 
are not names, and mixing them up is one of the worst possible mistakes 
a network architect could make. 


That means that whilst you might see 
WORLI.AMPR.ORG 
or 

BBS.WORLI.AMPR.ORG 
you won't see 
WORLI.#FNNI.NJ.USA.NOAM.AMPR.ORG 
or the like 


Ever. 
- Brian 


End of Ham-Digital Digest V94 #98 
KAKKKKKKKKKKKKKAKKKKKKKKKEKR KAKA 
KKKKKKKKKKKKKKKKKKKKKKEKKERKA KAKA 


